layers: describe policy enforcement for foreign layer media type #233

stevvooe · 2016-09-01T00:35:17Z

Signed-off-by: Stephen J Day [email protected]

Supersedes #216, Requires #169.

philips · 2016-09-01T01:28:07Z

@stephenrwalli Can you take a look at this language? I am still unclear if "MUST NOT distribute" is something we can define usefully in a spec.

I totally get it as a human being with context on copyrights for proprietary software about the usefullness. I just don't know how to codify this. It is like the evil bit RFC: https://www.ietf.org/rfc/rfc3514.txt

wking · 2016-09-01T16:49:54Z

layer.md

+Typically, one can download such layers but they should never be uploaded.
+
+Layers that have these restrictions SHOULD be tagged with an alternative mediatype of `application/vnd.oci.image.serialization.rootfs.foreign.tar.gzip`.
+[Descriptors][descriptor.md] referencing these layers MAY include `urls` for downloading these layers.


[Descriptors][descriptor.md] → [Descriptors](descriptor.md).

wking · 2016-09-02T13:57:32Z

layer.md

+Certain layers, due to legal requirements, may not be regularly distributable.
+Typically, one can download such layers but they should never be uploaded.
+
+Layers that have these restrictions SHOULD be tagged with an alternative mediatype of `application/vnd.oci.image.serialization.rootfs.foreign.tar.gzip`.


Pre-#212 media type pattern?

Yes, good catch!

jlbutler · 2016-09-03T00:21:02Z

media-types.md

- `application/vnd.oci.image.layer.tar+gzip`: ["Layer", as a gzipped tar archive](layer.md)
 - `application/vnd.oci.image.config.v1+json`: [Container config JSON](serialization.md)
+- `application/vnd.oci.image.layer.tar+gzip`: ["Layer", as a gzipped tar archive](layer.md)
+- `application/vnd.oci.image.layer.foreign.tar+gzip`: ["Layer", as a gzipped tar that should never be pushed](layer.md#foreign-layers)


Since a foreign layer must not be pushed per the layer spec, might this media type be better defined as "must not be pushed" rather than "should never be pushed"?

Possibly better to redefine "as a non-redistributable gzipped tar archive", or similar.

jonboulle · 2016-09-06T16:06:11Z

-1 on the underspecified use of the "push" verb, as discussed in #216 (comment)

stevvooe · 2016-09-06T18:59:35Z

@jonboulle It is sufficient to comment inline on the specific language that needs correcting rather than saying "-1". It is much more constructive, unless you intend to block the PR.

I've replaced the term "push" with the more generic "distribute".

stephenrwalli · 2016-09-06T20:58:49Z

@philips I understand your example. It's not necessarily how you would codify it, so much as it gives the certification process the language to revoke a certification based on non-compliance. While it might be difficult to write a test to prove the MUST NOT, if an implementation was demonstrated to distribute such a layer, it clearly doesn't do what the specification says, and would not be able to claim conformance/compliance. Likewise, for a certification process, one can design the process to manual test such a thing or to use the condition to revoke a certification until the implementation complies. Make sense? (Sorry for the tardy reply.)

wking · 2016-09-07T05:49:31Z

On Tue, Sep 06, 2016 at 01:58:50PM -0700, Stephen Walli wrote:

While it might be difficult to write a test to prove the MUST NOT,
if an implementation was demonstrated to distribute such a layer, it
clearly doesn't do what the specification says, and would not be
able to claim conformance/compliance. Likewise, for a certification
process, one can design the process to manual test such a thing or
to use the condition to revoke a certification until the
implementation complies.

“Yeah, automatically testing that would be hard, but we can manually
test it” is a marker for a wishy definition 1. I think the problem
here is that “distributing” is not something that one instance can do
by itself. If it's pushing a blob, someone else must be receiving it.
In some cases (e.g. pushing to a local disk on a single-user system),
that probably doesn't count as “distributing” in a legal sense. In
others (e.g. pushing to a public repo on hub.docker.com) it does.
Where does caching to disk on a multi-user system fall in that
continuum? Are you distributing it by saving to a system-readabale
cache? Or is it only distributing if another user on the system reads
it out of that cache? If that system-readable cache happens to live
under your home directory, are you being robbed (and not distributing)
when the other user reads the file?

I imagine there are consensus opinions on at least some of that
(although I'm not aware of them). I don't think we want to make it
the business of spec implementers and validators to independently
figure out what those opinions are. If there are conditions under
which you would certify (or not) an implementation, I'd like to see
those conditions spelled out in the spec in enough detail for them to
be objectively tested without appealing to “The average person,
applying local community standards, looking at the work in its
entirety” and such. In some cases, that wishyness is unavoidable.
But we need something more solid if we're expecting implementation
software to act consistently based on a ‘foreign’ boolean.

One option would be to have a CAS engine API (e.g. #159) where the
public/private-ness of the engine was part of its initialization.
E.g.:

casEngine, err := NewEngine(ctx, path, public)

Then the engine is non-compliant if you can successfully:

casEngine.Put(ctx, reader, mediaType)

with a foreign mediaType (this is testable by the OCI). And the
engine-initializer is breaking the law if they create a CAS engine
pointing at a public hub.docker.com repo and claiming it is not public
(this is between the CAS engine configurer and the copyright holders
of the pushed content, and not something the OCI has to certify).

philips · 2016-09-07T13:20:48Z

cc @runcom @vbatts ?

runcom · 2016-09-07T13:32:16Z

I'm not sure either on this one - is it an hard requirement for this spec to outline the legal matters of foreign layers? I (sorry I may be wrong) don't think so. I think as foreign layers just layers that are downloaded through a list of urls in a descriptor. Do we really need to clarify that those layers can't be distributed? I understand this was born in Docker for this exact legal reason but I don't think the spec should enforce this restriction (not to push) - if people end up pushing the layer it's them breaking any legal terms, I'm not sure what the spec has to do with this. (I believe it's perfectly possible to upload the Windows base layer by taking it and uploading it, implementers (Docker) enforce this, can we just add an implementor note? or add a SHOULD?)

(sorry if any of the above makes no sense...)

stephenrwalli · 2016-09-07T17:23:07Z

You make good sense, @runcom. So a way to call attention to such things, that I've seen in the past, is to explicitly call something out as implementation defined. This is basically a warning to spec implementers that are not part of the immediate spec community to pay attention in the space before naively doing something in their implementation. It also allows for the behaviors that already exist in implementations. So in this case, wording becomes: "It is implementation defined whether or not implementations distribute layers tagged with this media type."

jonboulle · 2016-09-07T17:28:24Z

Such a phrasing would definitely assuage my concerns about the vagueness of "pushing", "distributing", "distributable", etc. (My wariness is largely around combining such terms with the keyword MUST without being very explicit about what they mean.)

runcom · 2016-09-07T17:30:08Z

@stephenrwalli that sounds perfect to me if people agree

wking · 2016-09-07T17:56:45Z

layer.md

+# Foreign Layers
+
+Certain layers, due to legal requirements, may not be regularly distributable.
+Typically, one can download such layers but they should never be uploaded.


@RobDolinMS is going to quibble with this non-SHOULD should (e.g. opencontainers/runtime-spec#536 ;). How about dropping this line, since the idea is covered in the rest of this section?

This is an important clarification and frames the stronger language below. I can capitalize the SHOULD or re-phrase it.

On Wed, Sep 07, 2016 at 11:43:09AM -0700, Stephen Day wrote:

@@ -156,3 +156,13 @@ Note that this opaque file will apply to all children, including sub-directori
Implementations SHOULD generate layers using explicit whiteout files, but MUST accept both.

Any given image is likely to be composed of several of these Image Filesystem Changeset tar archives.
+
+# Foreign Layers
+
+Certain layers, due to legal requirements, may not be regularly distributable.
+Typically, one can download such layers but they should never be uploaded.

This is an important clarification and frames the stronger language
below.

What is this line adding beyond the earlier:

Certain layers, due to legal requirements, may not be regularly distributable.

and the planned 1:

It is implementation defined whether or not implementations
distribute layers tagged with this media type.

Can you pin down the information the other lines are missing that
you're trying to convey here?

I agree with @wking to drop this line and favor the new one proposed

wking · 2016-09-07T17:56:58Z

On Wed, Sep 07, 2016 at 10:23:08AM -0700, Stephen Walli wrote:

So in this case, wording becomes: "It is implementation defined
whether or not implementations distribute layers tagged with this
media type."

This works for me too.

wking · 2016-09-07T19:49:20Z

On Wed, Sep 07, 2016 at 10:23:08AM -0700, Stephen Walli wrote:

So in this case, wording becomes: "It is implementation defined
whether or not implementations distribute layers tagged with this
media type."

It feels awkard to repeat “implementation”. How about:

It is unspecified whether or not implementations distribute layers
tagged with this media type.

?

stephenrwalli · 2016-09-07T20:53:22Z

I believe the suggested text becomes:

Foreign Layers
Layers that have these restrictions SHOULD be tagged with an alternative mediatype of `application/vnd.oci.image.layer.foreign.tar+gzip`.
 [Descriptors](descriptor.md) referencing these layers MAY include `urls` for downloading these layers.
It is implementation defined whether or not implementations upload layers tagged with this media type.

stephenrwalli · 2016-09-07T20:56:08Z

@wking I appreciate the awkwardness of language, but I'm using very specific phrasing. "Unspecified" says you can do anything. "Implementation defined" is that bit stronger saying implementations may already do things here and you should pay attention to your choices.

philips · 2016-09-07T20:58:59Z

LGTM

wking · 2016-09-07T21:04:30Z

On Wed, Sep 07, 2016 at 01:56:09PM -0700, Stephen Walli wrote:

@wking I appreciate the awkwardness of language, but I'm using very
specific phrasing. "Unspecified" says you can do
anything. "Implementation defined" is that bit stronger saying
implementations may already do things here and you should pay
attention to your choices.

Interesting. It looks like C defines those terms [1,2]. If we are
going to split those hairs (and it sounds like a good idea to me), I'd
recommend we put something like that in our spec or reference another
spec to define them for us. Ideally the latter. Is there an
equivalent to RFC 2119 for these terms?

 Page 18 of the PDF, page 11 of the document.

runcom · 2016-09-07T21:07:37Z

Are we sticking with the current language?

stevvooe · 2016-09-07T21:40:51Z

Updated with the new language!

runcom · 2016-09-07T21:44:18Z

layer.md

+
+Layers that have these restrictions SHOULD be tagged with an alternative mediatype of `application/vnd.oci.image.layer.foreign.tar+gzip`.
+[Descriptors](descriptor.md) referencing these layers MAY include `urls` for downloading these layers.
+It is implementation defined whether or not implementations upload layers tagged with this media type.


s/upload/distribute?

@runcom I think there were concerns about the meaning of distribute. I'll change it to that if we can re-obtain consensus.

@stephenrwalli CC

@stevvooe sorry for the noise, I re-read and you're right..

wking · 2016-09-07T22:25:30Z

On Wed, Sep 07, 2016 at 02:40:52PM -0700, Stephen Day wrote:

Updated with the new language!

I still think we want to drop the “should never be uploaded” line 1,
and would like to define “implementation defined” 2. But those can
be addressed in follow-up work if they're too contentious to handle
now, and the rest of fbc6ce4 looks good to me.

philips · 2016-09-13T05:20:45Z

LGTM

stevvooe · 2016-09-13T19:12:14Z

🎊

runcom · 2016-09-13T19:20:05Z

🎉

I had been unaware of formal distinctions between these terms until Stephen Walli called it out [1] in the context of his suggestion to use "implementation defined" for uploading application/vnd.oci.image.layer.nondistributable.tar+gzip [2]. I couldn't find anything as compact as RFC 2119 around this idea, but linking to a section of the C99 rationale seems reasonable enough. The PDF I'm linking is "Rationale for International Standard - Programming Languages - C Revision 5.10 April-2003" and the referenced content appears in section 3: The terms *unspecified behavior*, *undefined behavior*, and *implementation-defined behavior* are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits *quality of implementation* to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of *conformance to the Standard*. Informative Annex J of the Standard catalogs those behaviors which fall into one of these three categories. *Unspecified behavior* gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program, however, because all possible behaviors are "correct" in the sense that they don't cause undefined behavior in *any* implementation. *Undefined behavior* gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. *Implementation-defined behavior* gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation's definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response. The "rationale for the C99 standard" link text seems pretty informal, but that's what WG14 uses to refer to the document [3]. And I've got the full title, revision, date, and referenced text in here in case the link dies and there is any ambiguity about the particular revision intended ;). [1]: opencontainers#233 (comment) [2]: opencontainers#233 (comment) [3]: http://www.open-std.org/jtc1/sc22/wg14/ Signed-off-by: W. Trevor King <[email protected]>

I had been unaware of formal distinctions between these terms until Stephen Walli called it out [1] in the context of his suggestion to use "implementation defined" for uploading application/vnd.oci.image.layer.nondistributable.tar+gzip [2]. I couldn't find anything as compact as RFC 2119 around this idea, but linking to a section of the C99 rationale seems reasonable enough. The PDF I'm linking is "Rationale for International Standard - Programming Languages - C Revision 5.10 April-2003" and the referenced content appears in section 3: The terms *unspecified behavior*, *undefined behavior*, and *implementation-defined behavior* are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits *quality of implementation* to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of *conformance to the Standard*. Informative Annex J of the Standard catalogs those behaviors which fall into one of these three categories. *Unspecified behavior* gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program, however, because all possible behaviors are "correct" in the sense that they don't cause undefined behavior in *any* implementation. *Undefined behavior* gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. *Implementation-defined behavior* gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation's definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response. The "rationale for the C99 standard" link text seems pretty informal, but that's what WG14 uses to refer to the document [3]. And I've got the full title, revision, date, and referenced text in here in case the link dies and there is any ambiguity about the particular revision intended ;). Also update the layer.md instance to use the C99 standard's hyphenated form. [1]: opencontainers#233 (comment) [2]: opencontainers#233 (comment) [3]: http://www.open-std.org/jtc1/sc22/wg14/ Signed-off-by: W. Trevor King <[email protected]>

I had been unaware of formal distinctions between these terms until Stephen Walli called it out [1] in the context of his suggestion to use "implementation defined" for uploading application/vnd.oci.image.layer.nondistributable.tar+gzip [2]. I couldn't find anything as compact as RFC 2119 around this idea, but linking to a section of the C99 rationale seems reasonable enough. The PDF I'm linking is "Rationale for International Standard - Programming Languages - C Revision 5.10 April-2003" and the referenced content appears in section 3: The terms *unspecified behavior*, *undefined behavior*, and *implementation-defined behavior* are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits *quality of implementation* to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of *conformance to the Standard*. Informative Annex J of the Standard catalogs those behaviors which fall into one of these three categories. *Unspecified behavior* gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program, however, because all possible behaviors are "correct" in the sense that they don't cause undefined behavior in *any* implementation. *Undefined behavior* gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. *Implementation-defined behavior* gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation's definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response. The "rationale for the C99 standard" link text seems pretty informal, but that's what WG14 uses to refer to the document [3]. And I've got the full title, revision, date, and referenced text in here in case the link dies and there is any ambiguity about the particular revision intended ;). [1]: opencontainers/image-spec#233 (comment) [2]: opencontainers/image-spec#233 (comment) [3]: http://www.open-std.org/jtc1/sc22/wg14/ Signed-off-by: W. Trevor King <[email protected]>

I had been unaware of formal distinctions between these terms until Stephen Walli called it out [1] in the context of his suggestion to use "implementation defined" for uploading application/vnd.oci.image.layer.nondistributable.tar+gzip [2]. I couldn't find anything as compact as RFC 2119 around this idea, but linking to a section of the C99 rationale seems reasonable enough. The PDF I'm linking is "Rationale for International Standard - Programming Languages - C Revision 5.10 April-2003" and the referenced content appears in section 3: The terms *unspecified behavior*, *undefined behavior*, and *implementation-defined behavior* are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits *quality of implementation* to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of *conformance to the Standard*. Informative Annex J of the Standard catalogs those behaviors which fall into one of these three categories. *Unspecified behavior* gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program, however, because all possible behaviors are "correct" in the sense that they don't cause undefined behavior in *any* implementation. *Undefined behavior* gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. *Implementation-defined behavior* gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation's definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response. The "rationale for the C99 standard" link text seems pretty informal, but that's what WG14 uses to refer to the document [3]. And I've got the full title, revision, date, and referenced text in here in case the link dies and there is any ambiguity about the particular revision intended ;). Also update the layer.md instance to use the C99 standard's hyphenated form. [1]: opencontainers/image-spec#233 (comment) [2]: opencontainers/image-spec#233 (comment) [3]: http://www.open-std.org/jtc1/sc22/wg14/ Signed-off-by: W. Trevor King <[email protected]>

…ds and config Non-distributable artifacts (foreign layers) were introduced in commit 05bd043 to accommodate Windows images, for which the EULA did not allow layers to be distributed through registries other than those hosted by Microsoft. The concept of foreign / non-distributable layers was adopted by the OCI distribution spec in [oci#233]. These restrictions were relaxed later to allow distributing these images through non-public registries, for which a configuration was added in the daemon in 67fdf57. In 2022, Microsoft updated the EULA and [removed these restrictions altogether][1], and the OCI distribution spec deprecated the functionality in [oci#965]. In 2023, Microsoft [removed the use of foreign data layers][2] for their images, making this functionality obsolete. This patch: - Deprecates the `--allow-nondistributable-artifacts` daemon flag and corresponding `allow-nondistributable-artifacts` field in `daemon.json`. Setting either option will no longer take an effect, but a deprecation warning log is added to raise awareness about the deprecation. This warning is planned to become an error in the next release. - Deprecates the `RegistryConfig.AllowNondistributableArtifactsCIDRs` and `RegistryConfig.AllowNondistributableArtifactsHostnames` fields in the `GET /info` API response. For API version v1.48 and lower, the fields are still included in the response, but always `null`. In API version v1.49 and higher, the field will be omitted entirely. - Deprecates the `api/types/registry/ServiceConfig.AllowNondistributableArtifactsCIDRs` field. - Deprecates the `api/types/registry/ServiceConfig.AllowNondistributableArtifactsHostnames` field. - Deprecates the `registry.ServiceOptions.AllowNondistributableArtifacts` field. [oci#233]: opencontainers/image-spec#233 [oci#965]: opencontainers/image-spec#965 [1]: https://techcommunity.microsoft.com/blog/containers/announcing-windows-container-base-image-redistribution-rights-change/3645201 [2]: https://techcommunity.microsoft.com/blog/containers/announcing-removal-of-foreign-layers-from-windows-container-images/3846833 Signed-off-by: Sebastiaan van Stijn <[email protected]>

Non-distributable artifacts (also called foreign layers) were introduced in docker v1.12 to accommodate Windows images for which the EULA did not allow layers to be distributed through registries other than those hosted by Microsoft. The concept of foreign / non-distributable layers was adopted by the OCI distribution spec in [oci#233]. These restrictions were relaxed later to allow distributing these images through non-public registries, for which a configuration was added in Docker v17.0.6.0. In 2022, Microsoft updated the EULA and [removed these restrictions][msft-3645201], followed by the OCI distribution specification deprecating foreign layers in [oci#965]. In 2023, Microsoft [removed the use of foreign data layers][msft-3846833] for their images, making this functionality obsolete. Docker v28.0 deprecates the `--allow-nondistributable-artifacts` daemon flag and corresponding `allow-nondistributable-artifacts` field in `daemon.json`. Setting either option no longer takes an effect, but a deprecation warning log is added to raise awareness about the deprecation. This warning is planned to become an error in the Docker v29.0. Users currently using these options are therefore recommended to remove this option from their configuration to prevent the daemon from starting when upgrading to Docker v29.0. The `AllowNondistributableArtifactsCIDRs` and `AllowNondistributableArtifactsHostnames` fields in the `RegistryConfig` of the `GET /info` API response are also deprecated. For API version v1.48 and lower, the fields are still included in the response but always `null`. In API version v1.49 and higher, the field will be omitted entirely. [oci#233]: opencontainers/image-spec#233 [oci#965]: opencontainers/image-spec#965 [msft-3645201]: https://techcommunity.microsoft.com/blog/containers/announcing-windows-container-base-image-redistribution-rights-change/3645201 [msft-3846833]: https://techcommunity.microsoft.com/blog/containers/announcing-removal-of-foreign-layers-from-windows-container-images/3846833 Signed-off-by: Sebastiaan van Stijn <[email protected]>

wking reviewed Sep 1, 2016
View reviewed changes

stevvooe force-pushed the foreign-layer-media-type branch from e7aa01a to 6c5b891 Compare September 1, 2016 17:40

runcom mentioned this pull request Sep 2, 2016

media-types.md: add foreign layer media type #216

Closed

wking reviewed Sep 2, 2016
View reviewed changes

stevvooe force-pushed the foreign-layer-media-type branch from 6c5b891 to 9b3d777 Compare September 2, 2016 21:21

jlbutler reviewed Sep 3, 2016
View reviewed changes

stevvooe force-pushed the foreign-layer-media-type branch from 9b3d777 to 4b60850 Compare September 6, 2016 18:56

wking reviewed Sep 7, 2016
View reviewed changes

philips added this to the v1.0.0 milestone Sep 7, 2016

stevvooe force-pushed the foreign-layer-media-type branch from 4b60850 to fbc6ce4 Compare September 7, 2016 21:40

runcom reviewed Sep 7, 2016
View reviewed changes

runcom mentioned this pull request Sep 12, 2016

specs-go/v1: add nondistributable media type #297

Merged

philips merged commit 2903142 into opencontainers:master Sep 13, 2016

stevvooe deleted the foreign-layer-media-type branch September 13, 2016 19:11

wking mentioned this pull request Sep 13, 2016

manifest: List media types supported by descriptor references #304

Merged

wking mentioned this pull request Sep 14, 2016

README: Define "unspecified", "undefined", and "implementation-defined" #311

Merged

wking mentioned this pull request Sep 18, 2016

[README] Add a should #323

Closed

wking mentioned this pull request Dec 8, 2016

layer: wordsmith non-distributable section #483

Merged

thaJeztah mentioned this pull request Dec 11, 2024

remove support for configuring pushing non-distributable artifacts and deprecate API fields and config moby/moby#49065

Merged

thaJeztah mentioned this pull request Jan 3, 2025

Deprecate configuration for pushing non-distributable artifacts docker/cli#5724

Merged

layers: describe policy enforcement for foreign layer media type #233

layers: describe policy enforcement for foreign layer media type #233

Uh oh!

Conversation

stevvooe commented Sep 1, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

philips commented Sep 1, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonboulle commented Sep 6, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stevvooe commented Sep 6, 2016

Uh oh!

stephenrwalli commented Sep 6, 2016

Uh oh!

wking commented Sep 7, 2016

Uh oh!

philips commented Sep 7, 2016

Uh oh!

runcom commented Sep 7, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stephenrwalli commented Sep 7, 2016

Uh oh!

jonboulle commented Sep 7, 2016

Uh oh!

runcom commented Sep 7, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wking commented Sep 7, 2016

Uh oh!

wking commented Sep 7, 2016

Uh oh!

stephenrwalli commented Sep 7, 2016

Uh oh!

stephenrwalli commented Sep 7, 2016

Uh oh!

philips commented Sep 7, 2016 • edited by caniszczyk Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wking commented Sep 7, 2016

Uh oh!

runcom commented Sep 7, 2016

Uh oh!

stevvooe commented Sep 7, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wking commented Sep 7, 2016

Uh oh!

philips commented Sep 13, 2016 • edited by caniszczyk Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stevvooe commented Sep 13, 2016

Uh oh!

runcom commented Sep 13, 2016

Uh oh!

Reviewers

Assignees

Labels

stevvooe commented Sep 1, 2016 •

edited

Loading

jonboulle commented Sep 6, 2016 •

edited

Loading

runcom commented Sep 7, 2016 •

edited

Loading

philips commented Sep 7, 2016 •

edited by caniszczyk

Loading

philips commented Sep 13, 2016 •

edited by caniszczyk

Loading